bors [Mon, 12 Feb 2018 22:02:00 +0000 (22:02 +0000)]
Auto merge of #5032 - matklad:lazycell, r=alexcrichton
Switch to lazycell from crate.io
This switches from a home-grown implementation of `lazycell` to the one from crates.io.
There are no particularly large improvements here, but our own lazy cell is definitely unsafe in theory, because of potential reentrancy in `get_or_try_init`, and the one from crates.io does not have at least this hole :-)
Note that `rustc` already has `lazycell` in its Cargo.lock (because of clippy I guess?), albeit with a lower version, 0.5.
Background: I was searching for cargo source code doc a while back, found the cargo book and crates.io doc relatively quickly but not the actual source code doc which I only found (after way to much time had passed) when I looked up the cargo crate on crates.io and found the "Documentation" link :/
Hope this improves the situation a bit in the future.
bors [Mon, 12 Feb 2018 17:53:00 +0000 (17:53 +0000)]
Auto merge of #5030 - alexcrichton:better-poll, r=matklad
Don't spin on empty fds in `read2` on Unix
This commit fixes what I think is some pathological behavior in Cargo where if
one stdio stream is closed before another then Cargo can accidentally spin in a
tight loop and not block appropriately. Previously, for example, if stderr
closed before stdout then Cargo would spin in a `poll` loop continuously getting
notified that stderr is closed.
The behavior is now changed so after a file descriptor is done we stop passing
it to `poll` and instead only pass the one remaining readable file descriptor.
Alex Crichton [Mon, 12 Feb 2018 17:27:11 +0000 (09:27 -0800)]
Don't spin on empty fds in `read2` on Unix
This commit fixes what I think is some pathological behavior in Cargo where if
one stdio stream is closed before another then Cargo can accidentally spin in a
tight loop and not block appropriately. Previously, for example, if stderr
closed before stdout then Cargo would spin in a `poll` loop continuously getting
notified that stderr is closed.
The behavior is now changed so after a file descriptor is done we stop passing
it to `poll` and instead only pass the one remaining readable file descriptor.
bors [Fri, 9 Feb 2018 18:50:24 +0000 (18:50 +0000)]
Auto merge of #5025 - Eh2406:error_mesges, r=alexcrichton
better resolver error messages
This is a start on beter resolver error messages. This is mostly trying to copy the `links` messages. In the process I found that we wor not testing the common case of having found candidates and still not resolving.
bors [Fri, 9 Feb 2018 00:22:00 +0000 (00:22 +0000)]
Auto merge of #5024 - debris:helpful_message, r=alexcrichton
Add helpful message when running cargo doc --open
Add helpful message when running cargo doc --open in the root of the workspace.
closes #4962
old output:
```
Documenting foo v0.1.0 (file:///Users/marek/projects/ethcore/tmp/dupa/foo)
Documenting bar v0.1.0 (file:///Users/marek/projects/ethcore/tmp/dupa/bar)
Finished dev [unoptimized + debuginfo] target(s) in 0.78 secs
error: Passing multiple packages and `open` is not supported
```
new output:
```
Documenting foo v0.1.0 (file:///Users/marek/projects/ethcore/tmp/dupa/foo)
Documenting bar v0.1.0 (file:///Users/marek/projects/ethcore/tmp/dupa/bar)
Finished dev [unoptimized + debuginfo] target(s) in 0.81 secs
error: Passing multiple packages and `open` is not supported.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
foo
bar
```
bors [Wed, 7 Feb 2018 02:06:13 +0000 (02:06 +0000)]
Auto merge of #5018 - brotzeit:clippy, r=alexcrichton
apply clippy suggestions
I want to try if this actually works =)
There are many other clippy suggestions. I wonder if I can take them for granted or if some of them would be refused.
For example:
```
warning: Constants have by default a `'static` lifetime
--> src/cargo/lib.rs:53:23
|
53 | pub const CARGO_ENV: &'static str = "CARGO";
| -^^^^^^^---- help: consider removing `'static`: `&str`
|
= note: #[warn(const_static_lifetime)] on by default
= help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.185/index.html#const_static_lifetime
```
bors [Tue, 6 Feb 2018 17:05:37 +0000 (17:05 +0000)]
Auto merge of #4834 - aidanhs:aphs-better-backtrack, r=alexcrichton
Make resolution backtracking smarter
There's no need to try every candidate for every dependency when backtracking - instead, only try candidates if they *could* change the eventual failure that caused backtracking in the first place, i.e.
1. if we've backtracked past the parent of the dep that failed
2. the number of activations for the dep has changed (activations are only ever added during resolution I believe)
The two new tests before:
```
$ /usr/bin/time cargo test --test resolve -- --test-threads 1 --nocapture resolving_with_constrained_sibling_
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/deps/resolve-19b2a13e5a19eed8
38.45user 2.16system 0:42.00elapsed 96%CPU (0avgtext+0avgdata 47672maxresident)k
0inputs+1664096outputs (0major+10921minor)pagefaults 0swaps
```
After:
```
$ /usr/bin/time cargo test --test resolve -- --test-threads 1 --nocapture resolving_with_constrained_sibling_
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/deps/resolve-19b2a13e5a19eed8
[...]
0.36user 0.01system 0:00.49elapsed 76%CPU (0avgtext+0avgdata 47464maxresident)k
0inputs+32outputs (0major+11602minor)pagefaults 0swaps
```
You observe the issue yourself with the following (it should fail, but hangs for a while instead - I didn't bother timing it and waiting for it to finish. With this PR it terminates almost instantly):
```
$ cargo new --bin x
Created binary (application) `x` project
$ /bin/echo -e 'serde = "=1.0.9"\nrust-s3 = "0.8"' >> x/Cargo.toml
$ cd x && cargo build
Updating registry `https://github.com/rust-lang/crates.io-index`
Resolving dependency graph...
```
bors [Tue, 6 Feb 2018 06:08:23 +0000 (06:08 +0000)]
Auto merge of #5013 - withoutboats:no-rust-rename, r=matklad
Do not rename packages on `cargo new`.
Prior to this commit, packages beginning with `rust` or ending with
`rs` were renamed automatically when created, unless they were
binaries. The ostensible purpose of this code was to avoid people
uploading "redundant" names to crates.io, which is a repository of
Rust packages.
This behavior was overly opinionated. It is not cargo's
responsibility to discourage users from naming their packages any
particular way. Without a sound technical reasons why packages
cannot be named a certain way, cargo should not be intervening in
users' package naming decisions.
It also did this by automatically renaming the package for the
user, as opposed to erroring. Though it printed a message about
the behavior, it did not give the user a choice to abort the
process; to overrule cargo they had to delete the new project
and start again using the `--name` argument.
`cargo new` is many users' first entrypoint to the Rust ecosystem.
This behavior teaches a user that Rust is opinionated and magical,
both of which are divisive attributes for a tool, and attributes
which do not generally describe Rust's attitude toward things like
names and formatting.
If crates.io wishes to enforce that users not upload packages with
names like this, it should be enforced by crates.io at publish
time.
boats [Mon, 5 Feb 2018 23:04:17 +0000 (15:04 -0800)]
Do not rename packages on `cargo new`.
Prior to this commit, packages beginning with `rust` or ending with
`rs` were renamed automatically when created, unless they were
binaries. The ostensible purpose of this code was to avoid people
uploading "redundant" names to crates.io, which is a repository of
Rust packages.
This behavior was overly opinionated. It is not cargo's
responsibility to discourage users from naming their packages any
particular way. Without a sound technical reasons why packages
cannot be named a certain way, cargo should not be intervening in
users' package naming decisions.
It also did this by automatically renaming the package for the
user, as opposed to erroring. Though it printed a message about
the behavior, it did not give the user a choice to abort the
process; to overrule cargo they had to delete the new project
and start again using the `--name` argument.
`cargo new` is many users' first entrypoint to the Rust ecosystem.
This behavior teaches a user that Rust is opinionated and magical,
both of which are divisive attributes for a tool, and attributes
which do not generally describe Rust's attitude toward things like
names and formatting.
If crates.io wishes to enforce that users not upload packages with
names like this, it should be enforced by crates.io at publish
time.
bors [Mon, 5 Feb 2018 21:22:16 +0000 (21:22 +0000)]
Auto merge of #4976 - mbrubeck:doc-check, r=alexcrichton
cargo doc: Generate rmeta files for dependencies instead of compiling rlibs
This makes `cargo doc` require only metadata (`.rmeta` files) instead of compiled libraries (`.rlib` files) for dependencies. This makes `cargo doc` faster in cases where rlibs are not already built and/or metadata is already available.
Unfortunately, this is not a win for every workflow. In the case where the user has already compiled but has not generated metadata, it makes `cargo doc` do extra work. This is probably a common case, though tools like RLS and `cargo check` mean that many developers *will* have up-to-date metadata available.
It would become an unequivocal win if `cargo build` and `cargo check` re-used shared metadata (#3501). For now, starting from a clean working directory, the following sequences of commands will become:
There's no need to try every candidate for every dependency - instead,
only try alternative candidates if they *could* change the eventual
failure that caused backtracking in the first place.
bors [Thu, 1 Feb 2018 19:12:19 +0000 (19:12 +0000)]
Auto merge of #4995 - alexcrichton:relative-env, r=matklad
Fix `RUSTC=./relative-path` when building
This commit adjusts the compiler location logic to resolve `./relative-path`
before invoking rustc to ensure it's no longer cwd-relative. This is how many
other variables like `CARGO_HOME` work, so it's applying similar logic.
Alex Crichton [Wed, 31 Jan 2018 18:30:01 +0000 (10:30 -0800)]
Fix `RUSTC=./relative-path` when building
This commit adjusts the compiler location logic to resolve `./relative-path`
before invoking rustc to ensure it's no longer cwd-relative. This is how many
other variables like `CARGO_HOME` work, so it's applying similar logic.
bors [Wed, 31 Jan 2018 09:20:32 +0000 (09:20 +0000)]
Auto merge of #4991 - bennofs:master, r=matklad
Require at least version 0.1.9 of jobserver crate
There are some important fixes in jobserver >=0.1.8. With earlier
versions, it's possible for cargo to panic with a "failed to acquire
jobserver token" error, which can be very hard to track down.
Requiring the latest version of jobserver makes sure that no such error
can make it into downstream distributions.
Benno Fünfstück [Wed, 31 Jan 2018 09:16:01 +0000 (10:16 +0100)]
Require at least version 0.1.9 of jobserver crate
There are some important fixes in jobserver >=0.1.8. With earlier
versions, it's possible for cargo to panic with a "failed to acquire
jobserver token" error, which can be very hard to track down.
Requiring the latest version of jobserver makes sure that no such error
can make it into downstream distributions.
bors [Wed, 24 Jan 2018 23:43:20 +0000 (23:43 +0000)]
Auto merge of #4974 - alexcrichton:less-vendor-verify, r=matklad
Be less strict about loading directory sources
Historically Cargo has been pretty strict about loading directory sources by
ensuring that everything inside was a crate. This was intended to protect
against accidental misconfiguration by failing loudly rather than silently
returning fewer crates.
This has caused a number of issues, however:
* #4969
* #4811
* #3899
so it seems like this is too aspirational of Cargo
Alex Crichton [Wed, 24 Jan 2018 18:04:47 +0000 (10:04 -0800)]
Be less strict about loading directory sources
Historically Cargo has been pretty strict about loading directory sources by
ensuring that everything inside was a crate. This was intended to protect
against accidental misconfiguration by failing loudly rather than silently
returning fewer crates.
This has caused a number of issues, however:
* #4969
* #4811
* #3899
so it seems like this is too aspirational of Cargo
bors [Wed, 24 Jan 2018 22:17:55 +0000 (22:17 +0000)]
Auto merge of #4973 - alexcrichton:dont-require-emscripten, r=matklad
Remove test that requires Emscripten
This seems relatively unlikely to regress in the future and otherwise arranging
Cargo to have a rustc that has Emscripten support will become difficult in the
near future in the Rust repo. All in all it seems like the course of action to
take is to delete this test for now.
Alex Crichton [Wed, 24 Jan 2018 17:45:01 +0000 (09:45 -0800)]
Remove test that requires Emscripten
This seems relatively unlikely to regress in the future and otherwise arranging
Cargo to have a rustc that has Emscripten support will become difficult in the
near future in the Rust repo. All in all it seems like the course of action to
take is to delete this test for now.
bors [Wed, 24 Jan 2018 15:05:11 +0000 (15:05 +0000)]
Auto merge of #4972 - varkor:lazy-cell-unused-unsafe, r=alexcrichton
Allow unused_unsafe in LazyCell in preparation for lib change
https://github.com/rust-lang/rust/pull/47204 makes `UnsafeCell::into_inner` safe, which means `LazyCell::into_inner` will no longer need an `unsafe` block. `LazyCell` is a blocker for the change in Rust: this fix should allow the change to take place.
varkor [Wed, 24 Jan 2018 09:46:54 +0000 (09:46 +0000)]
Allow unused_unsafe in LazyCell in preparation for lib change
https://github.com/rust-lang/rust/pull/47204 makes `UnsafeCell::into_inner` safe, which means `LazyCell::into_inner` will no longer need an `unsafe` block. `LazyCell` is a blocker for the change in Rust: this fix should allow the change to take place.
bors [Tue, 23 Jan 2018 22:10:46 +0000 (22:10 +0000)]
Auto merge of #4724 - pornel:sortpaths, r=alexcrichton
Sort native library paths for deterministic builds
Fixes #3800 by using a `BTreeSet`, which guarantees a deterministic iteration order.
Since the order was previously arbitrary, a sorted order is just as good. The list is so small, that any performance difference between `BTreeSet` and `HashSet` is negligible.
bors [Mon, 22 Jan 2018 20:55:15 +0000 (20:55 +0000)]
Auto merge of #4970 - Gilnaa:master, r=alexcrichton
Relaxed testing of libtest outputs.
This PR relaxes some checks on libtest due to upcoming changes by this PR:
https://github.com/rust-lang/rust/pull/46450
Summary of expected changes:
- Crashing benchmarks are now caught and handled just like in tests, and should not crash the harness. The old cargo test checked that the panic text was printed in stderr. In the patched behaviour, the text is printed to stdout.
With the advice of @alexcrichton, I changed test to check for the text in either stream in order to account of the transition period.
bors [Mon, 22 Jan 2018 15:33:14 +0000 (15:33 +0000)]
Auto merge of #4968 - edunham:patch-1, r=alexcrichton
Link to crate type docs
This page (served at https://doc.rust-lang.org/cargo/reference/manifest.html) is the first hit I get when searching "cargo crate-type". The doc which actually explains `crate-type`, https://doc.rust-lang.org/reference/linkage.html, does not appear in the first page of results. I hope that linking the reference doc here will make it easier for others to find instead of having to dig into closed GitHub issues like I did to find it.
E. Dunham [Mon, 22 Jan 2018 05:39:27 +0000 (21:39 -0800)]
Link to crate type docs
This page (served at https://doc.rust-lang.org/cargo/reference/manifest.html) is the first hit I get when searching "cargo crate-type". The doc which actually explains `crate-type`, https://doc.rust-lang.org/reference/linkage.html, does not appear in the first page of results. I hope that linking the reference doc here will make it easier for others to find instead of having to dig into closed GitHub issues like I did to find it.
Ted Mielczarek [Thu, 18 Jan 2018 19:51:40 +0000 (14:51 -0500)]
Add a missing link in the book for `jobserver`. I don't know what the original
intended link destination was, so I chose to link to the GNU Make documentation.
bors [Wed, 17 Jan 2018 16:22:07 +0000 (16:22 +0000)]
Auto merge of #4950 - alexcrichton:rustflags-orderd, r=matklad
Ensure `[target]` rustflags are deterministically passed
The usage of `HashMap` in the `Config` tables introduced some nondeterminism, so
reverse that with a sort right before we pass it down to rustc. One day we'll
probably want to sort by the position where these keys were defined, but for now
a blanket sort should do the trick.
bors [Wed, 17 Jan 2018 15:39:58 +0000 (15:39 +0000)]
Auto merge of #4949 - alexcrichton:fix-patch-network, r=matklad
Fix `[patch]` sections depending on one another
This commit fixes a bug in `[patch]` where the original source is updated too
often (for example `Updating ...` being printed too much). This bug occurred
when patches depended on each other (for example the dependencies of a resolved
`[patch]` would actually resolve to a `[patch]` that hadn't been resolved yet).
The ordering of resolution/locking wasn't happening correctly and wasn't ready
to break these cycles!
The process of adding `[patch]` sections to a registry has been updated to
account for this bug. Instead of add-and-lock all in one go this commit instead
splits the addition of `[patch]` into two phases. In the first we collect a
bunch of unlocked patch summaries but record all the `PackageId` instances for
each url we've scraped. After all `[patch]` sections have been processed in this
manner we go back and lock all the summaries that were previously unlocked. The
`lock` function was updated to *only* need the map of patches from URL to
`PackageId` as it doesn't actually have access to the full `Summary` of patches
during the `lock_patches` method.
All in all this should correctly resolve dependencies here which means that
processing of patches should proceed as usual, avoiding updating the registry
too much!
Alex Crichton [Tue, 16 Jan 2018 19:22:40 +0000 (11:22 -0800)]
Ensure `[target]` rustflags are deterministically passed
The usage of `HashMap` in the `Config` tables introduced some nondeterminism, so
reverse that with a sort right before we pass it down to rustc. One day we'll
probably want to sort by the position where these keys were defined, but for now
a blanket sort should do the trick.
Alex Crichton [Tue, 16 Jan 2018 15:33:59 +0000 (07:33 -0800)]
Fix `[patch]` sections depending on one another
This commit fixes a bug in `[patch]` where the original source is updated too
often (for example `Updating ...` being printed too much). This bug occurred
when patches depended on each other (for example the dependencies of a resolved
`[patch]` would actually resolve to a `[patch]` that hadn't been resolved yet).
The ordering of resolution/locking wasn't happening correctly and wasn't ready
to break these cycles!
The process of adding `[patch]` sections to a registry has been updated to
account for this bug. Instead of add-and-lock all in one go this commit instead
splits the addition of `[patch]` into two phases. In the first we collect a
bunch of unlocked patch summaries but record all the `PackageId` instances for
each url we've scraped. After all `[patch]` sections have been processed in this
manner we go back and lock all the summaries that were previously unlocked. The
`lock` function was updated to *only* need the map of patches from URL to
`PackageId` as it doesn't actually have access to the full `Summary` of patches
during the `lock_patches` method.
All in all this should correctly resolve dependencies here which means that
processing of patches should proceed as usual, avoiding updating the registry
too much!
bors [Tue, 16 Jan 2018 06:11:46 +0000 (06:11 +0000)]
Auto merge of #4944 - mathstuf:better-gitignore-template, r=alexcrichton
cargo_new: drop the trailing slash for target exclusion in Git
When `target` is a symlink (e.g., to keep build outputs on a separate
partition), Git will not match the `/target/` ignore to the symlink
since it is not a directory. Drop the trailing slash to support ignoring
`target` as a symlink.
Ben Boeckel [Mon, 15 Jan 2018 22:07:56 +0000 (17:07 -0500)]
cargo_new: drop the trailing slash for target exclusion in Git
When `target` is a symlink (e.g., to keep build outputs on a separate
partition), Git will not match the `/target/` ignore to the symlink
since it is not a directory. Drop the trailing slash to support ignoring
`target` as a symlink.
bors [Sat, 13 Jan 2018 23:59:50 +0000 (23:59 +0000)]
Auto merge of #4938 - ehuss:ws-meta, r=alexcrichton
Add workspace root to metadata command.
Fixes #4933
@alexcrichton, you mentioned using `"workspace_manifest"`, but the `Workspace.root` function already strips off `Cargo.toml`. It would be easy to append it back, though I'm uncertain if that's really necessary since I think for most use cases it will just need to be stripped off again. Also, I feel like it might be confusing for non-workspace packages since `workspace_manifest` would be the same as the package `manifest_path` (and in that case it isn't really a workspace manifest). I can easily change it, just let me know.